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ABSTRACT 

ESA has developed standards for packet 
telemetry (Ref.2) and telecommand (Ref.3), 
which are derived from the recommendations 
of the Inter-Agency Consultative Committee for 
Space Data Systems (CCSDS). These 
standards are now mandatory for future ESA 
programmes as well as for many programmes 
currently under development. However, whilst 
these packet standards address the end-to-end 
transfer of telemetry and telecommand data 
between applications on the ground and 
Application Processes on-board, they leave 
open the internal structure or content of the 
packets. 

This paper presents the ESA Packet 
Utilisation Standard (PUS) (Ref.1) which 
addresses this very subject and, as such, 
serves to extend and complement the ESA 
packet standards. The goal of the PUS is to 
be applicable to future ESA missions in all 
application areas (Telecommunications, 
Science, Earth Resources, microgravity etc.). 
The production of the PUS falls under the 
responsibility of the ESA Committee for 
Operations and EGSE Standards (COES). 

Keywords: Packet Utilisation, Packet 

Structure, COES. 

1. INTRODUCTION 

In the past, the monitoring and control of 
satellites was largely achieved at the 
"hardware" level. Telemetry parameters 
consisted of digitised read-outs of analogue 
channels and status information sampled from 
registers or relays. These parameters were 
sampled according to a regular pattern and 
appeared at fixed positions in a telemetry 
format. 

Similarly, control was performed using fixed- 
length telecommand frames which contained 


basic instructions for loading on-board 
registers or for enabling/disabling switches. 

Moreover, the associated space-ground 
communications techniques guaranteed 
neither a reliable nor a complete transmission 
of telemetry and telecommand data. 

Through the 1980s, there was a progressive 
increase in the use of on-board software to 
implement functions which should logically be 
performed on-board the satellite rather than on 
the ground e.g. control loops with short 
response times, data compression prior to 
downlink etc. However, this software had to 
be remotely monitored and controlled using 
the traditional hardware-oriented techniques. 

This imposed significant constraints on the on- 
board software implementation, limiting its 
flexibility and consequently hampering the 
trend towards more on-board intelligence and 
autonomy. 

In order to overcome these problems, the 
CCSDS recommended the use of telemetry 
and telecommand packets (Refs. 4 & 5) which 
provide a high quality space-ground 
communication technique enabling a flexible 
exchange of data between an on-board 
Application Process and a ground system. 
An Application Process is a logical on-board 
entity capable of generating telemetry packets 
and receiving telecommand packets for the 
purposes of monitoring and control. It is 
uniquely identified by an Application ID, which 
is used to establish an end-to-end connection 
between the Application Process and the 
Ground. Many different mappings can be 
envisaged between Application Processes and 
on-board hardware. At one extreme, each 
platform subsystem or payload (or part of 
thereof) could contain its own Application 
Process. In a more modest design, a single 
Application Process, say within the OBDH, 
could serve many, or even all the on-board 
subsystems and payloads. 
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The door was now open to implement a 
"message-type" interface between ground and 
space-based applications and thus to move 
towards the realisation of "process control" 
techniques. 

In 1987 ESA set up the Committee for 
Operation and EGSE Standards (COES). The 
primary objective of this group was to define 
those functions which are common between a 
satellite checkout system (EGSE) and a 
satellite control system. Even though these 
systems are used for different objectives and 
in different project phases, the logical interface 
to the satellite is identical and many of the 
functions are similar. Therefore, a common 
system could be used for the pre-launch 
checkout and post-launch mission operations 
both within a given project and also across 
different projects (see Fig.1). 




Fig. 1 Check-out / Operations Commonality 


COES decided to define such a common 
system for missions using the newly defined 
ESA Telemetry and Telecommand packets. 
However, the flexibility introduced by the use 
of packets leads to the possibility of 
implementing a given control function in many 
different ways. It soon became clear to COES 
that its task was only feasible if a clear 
satellite-ground interface existed, based on the 
use of packets. 

Consequently, the first task of the COES was 
to produce a standard which defined precisely 
how telemetry and telecommand packets 
should be used. 

2. SCOPE OF THE PUS 


The term "Utilisation" is used in the title of the 
standard, since the intention is that the PUS 
should address all aspects relating to the use 
of packets i.e. the circumstances under which 
they are generated and the rules for their 
exchange, as well as their structure, format 
and content. 


The PUS can therefore be seen as an 
interface document defining the relationship 
between space and ground. 

The PUS contains the following elements: 


operational requirements relating to 
satellite monitoring and control 
functions and to testability: 

standards for the secondary data 
header of telemetry and telecommand 
packets: 


the definition of a set of PUS Services 
which respond to the operational 
requirements. A Service specification 
includes the corresponding on-board 
Service model and a full definition of 
all the Service Data Units (SDUs) 
supported by the Service i.e. the 
telemetry and telecommand packets; 

standards for the data structures and 
parameter encoding types allowable 
within packets. 


The Operational Requirements cover all 
aspects of Nominal and Contingency 
Operations for the full spectrum of mission 
types and classes. They include generic 
requirements for: 
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the different classes of telemetry data 
to be transmitted to the ground and 
the circumstances under which the 
data shall be generated; 

the provision of different levels of 
telecommand access to the satellite to 
ensure the maximum degree of 
controllability; 

telecommand verification; 

the control of on-board software; 

the loading and dumping of on-board 
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memories. 


In addition, requirements are identified for a 
number of "advanced" on-board 
functionalities, which may only be required for 
particular classes of mission: 

on-board scheduling of commands for 
later automatic release; 

^ on-board parameter monitoring; 

C;:> on-board storage and retrieval of data; 

^ transfer of large data units (e.g. files) 

between space and ground and vice- 
versa. 

The requirements for Contingency operations 
cover the setting up of a "diagnostic" mode, 
wherein the ground can oversample selected 
telemetry parameters for ground evaluation 
purposes. Also, it should be possible to by- 
pass on-board functions by ground command 
and to operate a function in an off-line mode in 
order to isolate hardware faults. 

The Packet Data Field Header (PDFH) is left 
undefined within the ESA packet standards. 
However, the PUS identifies a fixed structure 
for this header for both telemetry 
telecommand packets, which is shown in 
Figure 2 below 
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Fig. 2 : Packet Data Field Headers 


The PDFH for telemetry and telecommand 
packets is identical, with the exception that a 
telemetry packet may (optionally) contain a 
time field for datation purposes. 

The version number allows for future versions 


of the data field header and possibly of other 
aspects defined by the PUS. For example, a 
new version could be defined for packets 
containing multiple Service Data Units as 
proposed by NASA/JPL for deep-space 
missions. 

The two most important fields in the PDFH 
identify the Service Type and the Service 
Subtype to which the packet relates. The 
specification of the "standard" Services 
provided by the PUS constitutes the bulk of 
the standard and these Services are covered 
in more detail in the next section. 

In principle, 256 Services and, for each 
Service, 256 Service Subtypes can be 
defined. The range from 0 to 127 is reserved 
for the PUS, in both cases, whilst the range 
from 128 to 255 is denoted as "mission- 
specific". The PUS thus has considerable 
growth capability for the later introduction of 
new Services or new Service Subtypes within 
an existing Service. 

3. PUS SERVICES 

At present, 17 PUS Services have been 
defined and these are listed in Table 1 below. 


Type 

Service Name 

1 

Telecommand Verification 

2 

Device Command Distribution 

3 

Housekeeping & Diagnostic 
Data Reportinq 

4 

Statistical Data Recoiling 

5 

Event Reportinq 

6 

Memory Manaqement 

7 

Task Manaqement 

8 

Function Manaqement 

9 

Time Manaqement 

10 

Time Packet 

11 

On-Board Schedulinq 

12 

On-board Monitorinq 

13 

Large Data Transfer 

14 

Packet Transmission Control 

15 

On-Board Storage and 

Retrieval 

16 

On-Board Traffic Manaqement 

17 

Test 
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Telecommand Verification Service 

Whilst none of the PUS Services is 
mandatory, it is expected that all Application 
Processes would implement this particular 
Service. Depending on the operational 
requirements and the on-board capabilities, 
commands can be verified at all stages: 
acceptance, start of execution, intermediate 
stages of execution and completion of 
execution. The selection of verification stages 
and whether positive as well as negative 
acknowledgement packets shall be generated 
can be done at the level of each individual 
command which is uplinked. 

Device Command Distribution Service 

There are 3 sub-services for the distribution of 
hardware-level commands: 

^ distribution at Telecommand Segment 

level; these commands require no 
software for their execution and 
would be used e.g. for unblocking or 
resetting the on-board Packet 
Assembly Controller (PAC); 

O distribution by the CPDU (Command 

Pulse Distribution Unit) within the 
decoder. These are high priority 
on/off commands which are 
distributed directly (hardwired) to on- 
board devices; 

c * > distribution by other Application 

Processes to devices, for example 
over an internal bus. Such 
commands may be used for normal 
operations or in a contingency 
situation e.g. where the normal higher- 
level control of the device is not to be, 
or cannot be, used. 

Housekeeping and Diagnostic Data 
Reporting Service 

The housekeeping sub-service covers the 
reporting of engineering data to the ground for 
monitoring and evaluation purposes. In order 
to adapt to changing operational conditions, 
the capability exists to define new 
housekeeping packets (or to re-define the 
contents of existing packets). Also, instead of 
systematically transmitting the housekeeping 


data to the ground, an optional "event-driven" 
mode is available. Event-driven means that 
the housekeeping packet is only generated if 
the value of a parameter within it varies by 
more than a prescribed threshold. 

The diagnostic sub-service is used to support 
ground-based troubleshooting, where high 
sampling rates may be required for selected 
parameters 

Statistical Data Reporting Service 

In addition to the direct reporting of 
engineering data to the ground, summary 
statistical data may also be provided, 
consisting of the reporting of maximum, 
minimum and mean values of specified 
parameters over a time interval. 

Event Reporting Service 

This Service covers reports of varying severity 
from "normal" reports (e.g. progress of 
operations) to the reporting of serious on- 
board anomalies. This provides the 
mechanism for on-board functions to report to 
the ground autonomous actions they have 
taken or events they have detected. 

Memory Management Service 

This covers all aspects of loading and 
dumping of on-board memory blocks, as well 
as performing checksums on specified 
memory areas on ground request. 

Task Management Service 

This Service allows the ground to exercise 
control (e.g. start, stop, suspend etc.) over on- 
board software tasks managed by an 
Application Process. For many missions, this 
level of control may only be exercised in 
contingencies. 

Function Management Service 

This Service provides the "normal" 
mechanism for control of the functions 
executed by an Application Process (e.g. 
activate, deactivate, pass parameters etc.) 

Time Management Service 

This service permits control over the on-board 
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generation rate of the Time Packet. In the 
future, this may be extended to cover the use 
of GPS. 

Time Packet Service 

This service is constituted solely of the Time 
Packet which is defined at the higher level of 
the ESA Packet Telemetry Standard (Ref.2). 

On-Board Scheduling Service 

For many missions, it will be necessary to load 
telecommands from the ground in advance of 
execution, for release on-board at a later time. 
For example, LEO missions, where operations 
must be conducted whilst outside of the limited 
ground passes. 

This Service provides the capability for 
loading, deleting, reporting and controlling the 
release-status of telecommands in an On- 
board Schedule. Telecommands may also be 
time-shifted, without the necessity of deleting 
and re-loading them with new times. 

A telecommand may also be "interlocked" to 
another telecommand, released earlier in time 
from the Schedule. That is to say, the release 
of the telecommand will be dependent on the 
success (or, alternatively, the failure) of the 
earlier command. 

On-Board Monitoring Service 

This Service provides some of the basic 
telemetry monitoring functions which are 
normally implemented on the ground i.e. 
mode-dependent limit, trend and fixed-status 
checking. Out-of-limit conditions are 
automatically reported to the ground. 

Large Data Transfer Service 

For many mission, it is anticipated that the 
largest desirable packet size may be much 
bigger than the maximum allowed by the ESA 
standards. This Service provides for the 
reliable transfer of a large Service Data Unit of 
any Type (e.g. a file, a large memory load 
block or a large report) by means of a 
sequence of smaller packets. The Service 
may be invoked either for the uplink or the 
downlink of a large Service Data Unit. 


This Service permits the enabling and 
disabling of the transmission of packets (of 
specified Type/Sub-type) from an Application 
Process. 

On-Board Storage and Retrieval Service 

This Service allows for the selective storage of 
packets for downlink at a later time under 
ground control. 

In principle, a number of independent stores 
may exist, which may be used for different 
operational purposes. For example, for 
missions with intermittent ground coverage, 
packets of high operational significance (e.g. 
anomaly packets) could be stored in a 
dedicated packet store so that they may be 
retrieved first during the next period of 
coverage. 

A "lost packet recovery" capability may also be 
achieved by systematically storing all event- 
driven packets on-board. 

On-Board Traffic Management Service 

This Service provides the capability to monitor 
the on-board packet bus (e.g. its load, the 
number of re-transmissions etc.) and to 
exercise ground control over on-board traffic 
and/or routing parameters or problems. 

Test Service 

This Service provides the capability to activate 
test functions on-board and to report the 
results of such tests in the telemetry. A 
standard Link Test ("Are you alive?") Sub- 
service is provided. 

4. MISSION-TAILORING 

An important aspect for the wider acceptance 
of the PUS is that it should be easily to tailor it 
to the specific requirements of a given 
mission. 

This consideration has been at the forefront 
whilst developing the standard and is achieved 
by the following measures: 

^ a mission may choose to implement 
only that sub-set of the PUS Services 
(and/or Sub-services) which it deems 


Packet Transmission Control Service 
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appropriate to its requirements; 

^ the structures defined for the Service 
Data Units (the telecommand and 
telemetry packets) identify "mission- 
optional" fields. These correspond to 
the "optional" capabilities within a 
Service (the so-called Capability 
Sets). If a capability set is not 
implemented for a particular Service, 
then the corresponding mission- 
optional fields may be omitted; 

^ for the data type of each field of the 
Service Data Units, the PUS only 
specifies the encoding type (e g. real 
or integer) with the encoding length 
being specified at mission-level; 

Thus, a mission may remain fully compliant 
with the PUS whilst incurring no detrimental 
impact on its packet overhead as a 
consequence. 

5. VALIDATION 

Prior to approval of the PUS, and before 
implementing supporting infrastructures, it was 
necessary to ensure the correctness, 
practicability and operational usefulness of the 
standard. This was achieved by means of a 
prototyping exercise completed in 1992, which 
both validated the standard and, at the same 
time, provided some indicators for possible 
implementation techniques. 

The packet communication techniques were 
not addressed in this prototype since these 
have already been independently 
demonstrated. Instead, the prototype 
concentrated on the end-to-end application- 
level aspects, emulating the on-board 
behaviour in response to the Ground control 
system. 

This prototype (called PUSV) runs on one or 
two SPARC workstations and at the same time 
allows modelling of different on-board 
Application architectures. A reference satellite 
model (called PUSSAT) was implemented for 
validation and demonstration purposes. 

6. FUTURE PERSPECTIVE 

Following an exhaustive review at Agency 


level during the course of 1993, the PUS in its 
present version was approved by the ESA 
inspector General and thus is now an Agency 
standard. 

The PUS is expected to evolve in the future, in 
an incremental manner, as new monitoring 
and control Services become sufficiently 
mature to be generalised and thus 
standardised. 

ESOC is currently undertaking a major 
mission control Infrastructure development, 
the so-called SCOS-II, which is a distributed 
system based on SUN workstations. SCOS-II 
will provide full application-level support to 
missions conforming with the PUS. 

COES is also specifying the functional 
requirements for a generic system to be used 
for checkout and operation across different 
projects. 
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